This invention relates generally to standard request-response protocols such as the HyperText Transport Protocol (HTTP), and more specifically to providing of a client-server protocol support list for such protocols.
The HyperText Transport Protocol (HTTP) has emerged as the standard mechanism by which information is transported over TCP/IP (Transmission Control Protocol/Internet Protocol) compatible networks, such as the Internet, intranets, and extranets. HTTP is more specifically an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol that can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers. It is referred to as a transport protocol, since information is transported according to its specifications, and is also referred to as a request-response protocol, since information is exchanged by a client making a request of a server, which generates a response thereto. HTTP as referred to herein refers generally to any standard of HTTP, and specifically to HTTP/1.1, as described in the Request for Comment (RFC) 2616, and available on the web site http://www.w3.org.
A common use of HTTP is the transport of information formatted according to a markup language. For example, a popular application of the Internet is the browsing of world-wide-web pages thereof. In such instances, typically the information retrieved is in HyperText Markup Language (HTML) format, as transported according to HTTP. However, other standard markup languages are emerging. One such markup language is eXtensible Markup Language (XML). XML describes a class of data objects that are referred to as XML documents, and partially describes the behavior of computer programs that process them. A primary difference between HTML and XML is that within the former, information content is intertwined with the layout of the content, making their separation difficult, for example. Conversely, within XML a description of the storage layout and logical structure of content is maintained separate from the content itself. However, both XML and HTML are subsets of a markup language known as Standard Generalized Markup Language (SGML). XML as referred to herein refers generally to any standard of XML, and specifically to XML 1.0, as described in the W3C recommendation REC-xml-19980210 dated Feb. 10, 1998, and also available on the web site http://www.w3.org.
HTTP, and hence XML in the context of HTTP, allows for the access of resources. The term resource refers to any piece of information that has a location described by a Uniform Resource Locator (URL) of the form HTTP:// less than domain greater than . less than domain-extension greater than / less than sub greater than / less than resource greater than . less than resour.extension greater than , where  less than domain greater than  specifies a particular domain,  less than sub greater than  is a subdirectory,  less than resource greater than  is a resource,  less than domain-extension greater than  can be, for example, .com, .edu, and net, among others, and  less than resource.extension greater than  can be, for example, .txt, .html, jpg, .gif, etc. A resource can be, for example, a Web page, a hierarchical collection of information such as folders, a document, a database, a bitmap image, or a computational object. Recently, extensions to HTTP have been proposed that, among other things, allow for better access to resources over HTTP. The extensions are generally referred to as the World-Wide-Web Distributed Authoring and Versioning (WebDAV) extensions to HTTP. The goal of WebDAV, broadly speaking, has been to add remote authoring capabilities to HTTP, so that HTTP can be more convenient as a readable and writable collaborative medium, and not necessarily only a browsing medium for web pages.
WebDAV is generally described in the reference E. James Whitehead, Jr., World-Wide-Web Distributed Authoring and Versioning (WebDAV): An Introduction, in StandardView, Vol. 5, No. 1, March 1997, pages 3-8. WEBDav is also described in the reference Internet Engineering Task Force (IETF) Request for Comment (RFC) 2518, entitled HTTP Extensions for Distributed Authoring, by Y. Goland, E. Whitehead, A. Faizi, S. Carter and D. Jensen, and dated February 1999. Generally, this latter reference specifies a set of methods, headers and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, name space manipulation, and resource locking (also referred to as collision avoidance).
WebDAV can be referred to as a protocol by which a client communicates information with a server in the context of HTTP. However, WebDAV is not the only such protocol. For example, client-server communication can also be performed in accordance with the protocol set forth by the Microsoft(copyright) FrontPage(copyright) (hereinafter referred to as MFP) computer program, which is a program for designing web pages and managing web sites. A server may support both WebDAV and the MFP protocols, but may prefer one or the other. Or, a server may only support either the WebDAV or MFP protocol, for instance. Both WebDAV and MFP are extensions to HTTP protocols. A limitation to such protocols, and to HTTP generally, is that there is no manner by which a client is able to determine what protocols a server supports by querying the server, and, furthermore, is not able to determine which protocol of those supported by a server that the server prefers. For these and other reasons, there is a need for the present invention.
The invention provides for a client-server protocol support list in the context of standard request-response protocols such as HTTP. In one embodiment, a method for a server includes receiving a request according to a predetermined transport protocol such as HTTP. In response to receiving the request, the method transmits a list of supported client-server protocols in order of server preference, in accordance with the predetermined transport protocol. In one embodiment, the request is an OPTIONS request under HTTP. In one embodiment, the list is not a complete list of the protocols supported by the server.
Embodiments of the invention provide for advantages not found within the prior art. For example, a client is able to query a server to determine an ordered list of protocols that the server supports in the context of a transport protocol like HTTP. The client can then use the protocol most preferred by the server that the client also supports. This ensures that the client is communicating with the server not only via a protocol support by the server, but also via a protocol that the server most prefers, insofar as that protocol is also supported by the client. Furthermore, embodiments of the invention are applicable to protocols other than HTTP protocols, such as Gopher and File Transfer Protocol (FTP).